As is known in the art, content (text, music, pictures, video, etc.) may be digitally encoded in one of many public or proprietary formats and sent as a file and/or streamed to consumers, optionally including the use of digital rights management (“DRM”) technologies to authenticate and authorize use of the content. The encoded content may also comprise or otherwise be associated with metadata; metadata may comprise information regarding the content, such as author, track, title, episode, length, captions, etc., and/or information regarding how the content was encoded and/or about how the content may be decoded, such as file format, sample rate, whether the content was recorded in stereo, a video aspect ratio, methods of error correction, license information, a decryption key, etc., and/or information regarding or by one or more of the parties involved with encoding, storing, or distributing the content, such as an identifier for the party and/or a watermark or similar. Certain of the information in the metadata may be obtained directly from the metadata (assuming access to the metadata and knowledge of how the information is encoded in the metadata) while other of the information may require additional steps, such as obtaining an identifier, URI, address or other identifier from the metadata, which identifier may be used as a reference to obtain (from a database or at another resource or data source) additional information, such as an identify of a party, a decryption key, or similar.
Also as is known, content may be encoded in a file structure comprising a header block and a content data block. Generally speaking, the header block may comprise metadata while the content block comprises the encoded content. The file structure may comprise one or more header blocks associated with one or more content data blocks, often in multiple sequential pairs. For example, an MPEG-1 Audio Layer 3 (“MP3”) file may comprise a sequence of MP3 frames (including media-data), which sequence may further be encapsulated in or by an ID3 metadata container (such a metadata container also being referred to herein as an instance of a header comprising metadata).
Also as is known, the content in content files may be encrypted or otherwise cryptographically protected through various DRM systems, in which case the header may be an integral part of (e.g. bound to) the content file such that the content file is not usable without the header, some or all of which header may also be encrypted or otherwise cryptographically protected by a DRM system. Even in the context of content files which are not encrypted, it is useful to be able to reliable track the supply chain, purchaser, and/or use of a particular content file, which may involve binding the header and content together in the content file in a secure or tamper resistant manner.
A provider of content packaging and delivery services, content packager, may be asked by seller A to prepare and/or store content files for different parties, such as resellers B and C, who in turn sell or otherwise provide the content files to consumers. The resulting content files contain the same underlying content, but may have different revocation and authentication URLs or may otherwise have different metadata bearing headers associated with the various distributors (e.g., seller A and resellers B and C) in the supply chain.
Needed is a method and system which can prepare and/or bind and/or provide multiple sets of headers in relation to a common content instance. The preparation and/or binding and/or providing may be performed dynamically (on demand) or in advance and may be performed so as to eliminate or reduce the need to store potentially redundant content data or to eliminate or reduce the amount of processing required to bind the different headers to the content data.